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CROSS-REFERENCE TO RELATED APPLICATIONS 

[001] This application relates to applications, Attorney Docket Nos. 
06502.0338.00000, entitled "METHODS AND SYSTEM FOR DEFINING AND CREATING 

' CUSTOM ACTIVITIES WITHIN PROCESS MANAGEMENT SOFTWARE," 
06502.0339.00000, entitled "METHODS AND SYSTEM FOR INTEGRATING XML BASED 
TRANSACTIONS IN AN ELECTRONIC INVOICE PRESENTMENT AND PAYMENT 
ENVIRONMENT," and 06502.0341.00000, entitled "METHODS AND SYSTEM FOR 
PERFORMING BUSINESS-TO-BUSINESS ELECTRONIC INVOICE PRESENTMENT AND 

,: PAYMENT WITH LINE ITEM LEVEL GRANULARITY," filed concurrently with the present 
application, owned by the assignee of this application and expressly incorporated herein by 
reference in their entirety. 

DESCRIPTION OF THE INVENTION 

Field of the Invention 

\\ [002] This invention relates to electronic invoice presentment and payment systems 

ij 

;! and, more particularly, to methods, systems and articles of manufacture for performing business- 
. to-business invoice dispute handling at a line item level of granularity. 

Background of the Invention 

[003] Businesses charge for goods and/or services that they provide and customers who 
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and/or services are typically associated with a business' operating costs^ the transaction costs 
associated with managing billing operations are sometimes overlooked. 

[004] Currently, businesses spend millions of dollars to process account information 
and bill customers. Billing systems and processes are predominately paper based and are 
conducted through human interaction. The billing costs associated with paper, handling and 
postage, not to mention the availability of ftinds, increases with each new customer a business 
serves. 

[005] Today, to offset the costs of managing its billing operations, businesses have 
entertained the implementation of Business-to-Customer (B2C) hitemet Bill presentment and 
Payment (IBPP) systems. By implementing an IBPP system, business may allow customers to 
view, store and pay recurring bills using a Web browser, e-mail, or personal financial 
management software. Accordingly, the IBPP market is growing in popularity due to its inherent 
benefit of reducing the costs associated with billing operations. 

[006] Based on the success of business-to customer (B2C) based IBPP systems, 
businesses have contemplated the implementation of IBPP concepts to business- to-business 
(B2B) markets. Through this foresight, Electronic Invoice Presentment and Payment (EIPP) 
systems have evolved. The business-to-business (B2B) EIPP market represents a significant 
departure from the business-to-customer (B2C) IBPP market. As with their counterpart, B2B 
EIPP systems allow businesses to save money through less paper work. However, in addition to 
these benefits, B2B EIPP systems also allow businesses to have more control over and insight 
into the entire invoice process, including disputing and recalculating their bills prior to payment. 

[007] Conventional B2B EIPP systems allow businesses to have invoices presented, 
processed and paid through an intermediate service. In doing so, the intermediate service 



2 



^ generally downloads an entire invoice from a provider of goods and/or services and enables the 
; invoice to be managed on-line by both the provider and a purchaser. Although such services 
enable businesses to perform invoice processes electronically, dispute and payment processing is 
\ limited to the entire invoice. That is, if the purchaser disputed a particular line item within an 
invoice, the entire invoice would have to be disputed. Thus, the inherent advantages of using on- 
line B2B invoice processing is nuUified by forcing the purchaser to contact the provider to 
! clarify the line items that are in dispute. Although current B2B EIPP systems, such as BizCast™ 
: from Avolent and NetTransact™ from Bottomline Technologies ®, manage invoices (such as 
tracking the status of individual line items), these systems do not allow line items to be processed 
according to a purchaser's specifications. 

SUMMARY OF THE INVENTION 

[008] It is therefore desirable to have a method and system that enables line items 
associated with invoices generated by a providing entity to be managed according to a 
customized approval management structure associated with a purchasing entity in order to 
facilitate line item dispute management operations. 

[009] Methods, systems and articles of manufacture consistent with the present 
invention enable a provider to provide information associated with invoices corresponding to one 
I or more purchasers to a server. The invoices may include one or more line items that designate 
goods and/or services provided by the provider. The line items may designate particular 
departments within a purchaser that received the goods and/or services. 

[010] Additionally, methods, systems and articles of manufacture enable the server to 
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purchaser requests to review invoice data that have been reviewed by subordinate approvers, the 
server presents a list of invoices directly associated with the designated approver's corresponding 
department. 

[Oil] Methods, systems and articles of manufacture consistent with the present 
invention enable the designated approver to view individual line items within selected invoices 
to approve (accept) or reject (dispute) purchases indicated in these individual line items. The 
server receives the designated approver's decisions associated with particular line items and 
initiates a dispute resolution process in the event the designated approver disputed one or more 
line items. The dispute resolution process may include making an indication of the disputed line 
items available to the provider, facilitating a provider resolution process whereby resolvers 
associated with the provider may dispute or approve the disputed line items reflected in the 
indication, and making the results of the provider resolution process available to the purchaser. 

[012] Additional advantages of the invention will be set forth in part in the description 
which follows, and in part will be obvious from the description, or may be learned by practice of 
the invention. The advantages of the invention will be realized and attained by means of the 
elements and combinations particularly pointed out in the appended claims. It is to be 
understood that both the foregoing general description and the following detailed description are 
exemplary and explanatory only and are not restrictive of the invention, as claimed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[013] The accompanying drawings, which are incorporated in and constitute a part of 
this specification, illustrate several embodiments of the invention and together with the 
description, serve to explain the principles of the invention. In the drawings, 



[014] FIG, 1 A illustrates an exemplary management structure for a purchasing entity 
consistent with features and principles of the present invention; 

[015] FIG. IB illustrates aa exemplary approver hierarchy consistent with features and 
principles of the present invention; 

[016] FIG. 2 A illustrates an exemplary system environment in which features and 
principles of the present invention may be implemented; 

[017] FIG. 2B, 2C, 2D and 2E illustrate exemplary block diagrams of processes 
performed by a biller manager process consistent with features and principles of the present 
invention; 

:. □ [018] FIG. 3 illustrates an exemplary structural view of multiple systems consistent with 

features and principles of the present invention; 
; L: [019] FIG. 4A illustrates an exemplary flowchart for manager approval processing 

consistent with features and principles of the present invention; 
m [020] FIG. 4B illustrates an exemplary flowchart for approver processing consistent 

with features and principles of the present invention; 

[02 1 ] FIG. 4C illustrates an exemplary flowchart for delegation approval processing 
ji consistent with features and principles of the present invention; 

[022] FIG. 4D illustrates an exemplary flowchart for invoice amount approval 
processing consistent with features and principles of the present invention; and 

[023] FIG. 4E illustrates an exemplary flowchart for dispute resolution processing 
consistent with features and principles of the present invention; 

LAW OFFICES ; [024] FIG. 5A illustrates an exemplary flowchart for processing an invoice consistent 
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[025] FIG. 5B illustrates an exemplary invoice consistent with features and principles of 
the present invention; 

[026] FIG. 6 illustrates exemplary summary and line item tables consistent with features 
and principles of the present invention; 

[027] FIG. 7 illustrates an exemplary subordinate approver in-box consistent with 
features and principles of the present invention; 

[028] FIG. 8 is an exemplary flowchart for processing a request from a subordinate 
approver consistent with features and principles of the present invention; 

[029] FIG. 9 illustrates an exemplary description of a line item invoice associated with a 
subordinate approver consistent with features and principles of the present invention; 

[030] FIG. 10 illustrates an exemplary flowchart for processing a request from a 
designated approver consistent with features and principles of the present invention; 

[03 1] FIG. 1 1 illustrates an exemplary designated approver in-box consistent with 
features and principles of the present invention; 

[032] FIG. 12 illustrates an exemplary description of a line item invoice associated with 
a designated approver consistent with features and principles of the present invention; and 

[033] FIG. 13 illustrates an exemplary flowchart for dispute resolution processing 
consistent with features and principles of the present invention. 

DETAILED DESCRIPTION 

[034] Methods, systems and articles of manufacture consistent with the present 
invention enable a purchasing entity to perform approval/dispute processing corresponding to 
invoices generated by a providing entity. An EIPP server facilitates the approval/dispute 
processing by collecting invoice information from a providing entity and structuring this 



information for use by the providing entity. The invoice information may be associated with one 
or more invoices that reflect purchases of goods and/or services by a purchasing entity. Each 
invoice may include one or more items corresponding to particular goods and/or services 
provided to a particular sub-entity associated with the purchasing entity. For example, the 
purchasing entity may be a corporation and the sub-entity may be a department within the 
: corporation. 

[035] The purchasing entity may utihze the EIPP server to customize an 
approval/dispute process associated with these invoices, hi one aspect of the invention, the 
purchasing entity may designate approvers, individuals authorized to review invoice items for 
each sub-entity. Additionally, a specific approval/dispute process may by defined that allows 
items that have been reviewed by particular approvers to be made available to other designated 
;^L: , approvers for further review. 

I/" [036] To allow the items in invoices to be made available for review, methods, systems 

j fi and articles of manufacture consistent with the present invention enable the EIPP server to 

generate an in-box similar to the in-box utihzed by known electronic mail software applications. 
The generated in-box provides information corresponding to items associated with a designated 
li approver associated with the purchasing entity who generated a request to review the invoice(s). 
hi one aspect of the invention, the in-box may include items that correspond to a sub-entity (or 
sub-entities) that the requesting approver is authorized to review, while excluding items that are 
associated with other sub-entities. 

[037] The requesting approver may review the items presented in the in-box, and either 

LAW OFFICES ; approve or dispute each item. The EffP server collects the approver's decisions and performs 
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In one aspect of the invention, the customized process may allow the approver's decisions to be 
made available to another approver who is authorized to review items associated with the sub- 
entity corresponding to the requesting approver. The EEPP server may generate another in-box 
associated with the second approver to facilitate additional approval/dispute processing for the 
items previously reviewed by the first requesting approver. 

[038] Methods, systems and articles of manufacture consistent with the present 
invention may also enable the purchasing entity to define an automatic approval process based 
on a monetary value of invoices or items within an invoice. Approved items may be made 
available to payment entities within the purchasing entity to facilitate payment to the providing 
entity for the goods and/or services associated with the approved items. Disputed items within 
an invoice, on the other hand, may be processed by a dispute resolution process managed by the 
EIPP server. The dispute resolution process makes an indication of the disputed items available 
to the providing entity, facilitates a provider resolution process whereby resolvers associated 
with the provider may dispute or approve the disputed items reflected in the indication, and 
allows the results of the provider resolution process to be made available to the purchasing 
entity. 

[039] The dispute resolution process facilitated by methods and systems consistent 
with features of the present invention enable providing and purchasing entities to perform 
dispute resolutions using consistent invoice data at a line item level of granularity, thus reducing 
the transaction costs associated with conventional electronic dispute processing systems. 

[040] Reference will now be made in detail to the exemplary embodiments of the 
invention, examples of which are illustrated in the accompanying drawings. Wherever possible. 
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[ the same reference numbers will be used throughout the drawings to refer to the same or like 
: parts. 

[041] In the B2C space, an invoice usually involves a single purchaser of goods and 
; services for a single business entity, hi the B2B space, however, complex relationships exist 
; between various departments, divisions, units, and, in the case of large conglomerates, even 
' completely separate businesses. Within single invoices, a purchasing entity needs to be able to 
assign line items to various entities (individuals, groups, departments, etc.) depending upon its 
needs. Accordingly, methods and systems consistent with the present invention enable a 
purchasing entity to define one or more approvers for line items within an invoice that may differ 
11 I from the purchasing entity's actual management hierarchical structure. 

[042] FIG. 1 A shows an exemplary portion of a purchasing entity' s management 
hierarchical structure 100. As shown in FIG. 1 A, an exemplary purchasing entity called 
''J "eCompany" includes a department 000 that is headed by manager 000. In turn, departments 

i 11 100, 200 and 300 are sub-departments of department 000, and are headed by managers 100, 200 

and 300, respectively. Managers 100, 200 and 300 each report to manager 000. Within each 
: sub-department, there may be further separation of individual units. As shown in FIG. lA, units 
jl 101 and 102, headed by managers 101 and 102, respectively, are sub-departments of department 
;; 100. Furthermore, units 201 and 202, headed by managers 201 and 202, respectively, are sub- 
departments of sub-department 200. 

[043] The hierarchical structure of a entity, such as the one shown in FIG. 1, can 
become quite complex, spanning multiple divisions, geographies and departments. The simple 
LAW OFFICES ,1 hicraTchical structure shown in FIG. 1 A is exemplary and is not intended to be limiting, but will 
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not intended to define a specific managerial level within a purchasing entity. The term 
"department" may be associated with any form of segregation of an entity that may include units, 
divisions, groups, sub-entities, or any other term that may be associated with a entity's structural 
business model. 

[044] FIG. IB illustrates an exemplary approval hierarchy associated with purchasing 
entity eCompany. As shown in FIG. IB, manager 000 is identified as an approver for all 
decisions made by managers defined below department 000 in the hierarchy. For instance, 
manager 000 is an approver for decisions made by managers 100, 200 and 300. In turn, each 
manager 100, 200 and 300 are approvers for decisions made within their respective departments 
and any underlying departments. Therefore, referring to FIG. 1 A, decisions made by managers 
101 and 102 are reviewed by manager 100, while decisions by managers 201 and 202 are 
reviewed by manager 200. As will be described later, a purchasing entity may customize their 
approval hierarchy in any manner deemed fit for their business. 

[045] Fig. 2A shows an exemplary system environment 200A in which features and 
principles consistent with the present invention may be implemented. As shown, system 
environment 200 A includes network 260 A, providing entity 21 OA, purchasing entity 220A, and 
EIPP server 240A. Also depicted in FIG. 2A are network interfaces 21 1 A, 221A and 230A that 
may connect their respective entities (and systems) to a network 260A, such as the Internet. 
Although FIG. 2A shows only one providing entity and purchasing entity, it is understood that 
any number of purchasing entities may be associated with one or more providing entities that 
may operate in accordance with the following description of providing entity 21 OA and 
purchasing entity 220A. Furthermore, system environment 200A may include a plurality of 
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! 
I 

, EIPP servers 240A that collectively perform the B2B EIPP features consistent with the present | 
invention. 

[046] Providing and purchasing entities 21 OA, 220 A, and EffP server 240 A, each may 
be implemented using virtually any type of computer system. For example, as shown in FIG. 
2 A, providing entity 21 OA, purchasing entity 220A and EIPP server 240A each may respectively 
include: a CPU system 21 3 A, 223 A, 241 A; an associated memory 217A, 227A, 245 A; and an 
input/output interface 215A, 225A and 243A, Providing entity 210A, purchasing entity 220A, 
and EIPP server 240 A may also include a number of other elements and functionalities (not 
shown) typical in today's computer systems. Providing entity 21 OA, purchasing entity 220 A and 
EIPP server 240A may each have associated with it an input means such as a keyboard and 

^ mouse (not shown). Also, entities 21 OA and 220A, as well as EIPP server 240 A, may also 

include an output device such as a display, that may generate graphical representations through 

1^ the use of a browser application executed by their respective CPU systems. These input and 

output means may take other forms as well without departing from the scope of the invention. i 

M [047] Providing entity 2 1 OA may represent a business entity that generates bills for its | 

^^ ■^^ customers in the form of invoices. Associated with providing entity 21 OA, may be personnel I 

;j that handle particular aspects of the biUing process. This billing personnel may include, but are I 

i 

not limited to: a system administrator who may administer the system component (such as I 
■ database controls, etc.); a company administrator who may mange access to the system and may j 
; also perform other business functions such as loading invoice data into the system; and dispute | 

, handlers who handle disputes from purchasing entities, such as purchasing entity 220 A, | 

1 
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[048] Purchasing entity 220A may represent a business that orders goods and/or 
services from providing entity 21 OA. Associated with purchasing entity 21 OA may be personnel 
that handle particular aspects of a payment process corresponding to invoices produced by 
providing entity 21 OA, The payment processing personnel may include, but is not limited to; a 
company administrator who manages user, company and organization information; approvers 
who are assigned invoices for approval; and payers who are authorized to pay invoices for 
purchasing entity 220A. For exemplary purposes, the approvers for purchasing entity 220 A may 
be those depicted in FIG. IB. 

[049] In one aspect of the invention, EIFP server interface 23 OA may include a web 
server (not shown) that acts as a proxy for requests that are received from providing and 
purchasing entities 21 OA, 220 A, respectively, and passes the requests to EIPP server 240 A for 
processing. The web server may also participate in dynamic load balancing operations when 
system 200A is implemented with multiple EIPP servers. In such an environment, incoming 
requests are received at the web server and a load balancing system may direct each request to an 
EIPP server that is determined to be the one best suited to process it. The types of load balancing 
that may be implemented include, but is not limited to: server load, response time, round robin 
and weighted round robin mechanisms. 

[050] EIPP server 240A performs the B2B EIPP functions in accordance with features 
and principles of the present invention. As shown in FIG. 2 A, the memory 245 A contained 
within EIPP server 240A may include a plurality of processes that are utilized by EIPP server 
240 A to perform functions consistent with features of the present invention. These processes 
may include, but are not limited to: a process manager 242A, a biller manager 244A, LDAP 
process 246A and Java Database Caller JDBC 248A. EIPP server 240A may provide dynamic 
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load balancing (working with the web server) and failure recovery. As previously mentioned, 
i EEPP server 240A maybe implemented with a plurality of servers that facilitate fauh tolerant 
■ operations. In the event one server fails, another server may take over to handle the requests 
previously processed by the failed server. EIPP server 240A may also implement automatic 
application restarting and maintain and repUcate distributed user-session information and 
distributed application-state information. In this manner, information may be maintained as long 
as more than one server installation is running in a cluster with the server that failed. 

[05 1] EIPP server 240A may be configured as a high performance, multi-threaded and 
multi-processing appUcation server. EIPP server 240A may handle a high number of concurrent 
requests, database connections, user sessions, and provide optimal performance under heavy 
loads through the use of: (1) database connection caching that enables EIPP server 240A to 
cache database connections so that common database connections are reused instead of 
reestabUshed; (1) result caching that enables EIPP server 240A to cache the results of appUcation 
logic so that if the same request is made again, the results in the cache may be used; (3) data 
streaming that enables the EPP server 240A to stream back results to the user as the data is 
, returned instead of waiting for the entire response to complete; and (4) multi-threaded 
I capabilities that enable application logic within EIPP server 240A to be processed on multiple 
- threads, thus allowing the appUcation to maximize CPU resources, 

[052] CoUectively, interface 230A, EIPP server 240A and database 250A may be 
configured as a Java 2 Platform, Enterprise Edition (J2EE). The J2EE platform comprises of a 
, set of services, appUcation programming interfaces (APIs) and protocols for developing web- 
based appUcations, For more information on the J2EE platform, see Steven Gould, Develop N- 
Tier Applications Using J2EE. An Introduction to Java 2 Platform. Enterprise Edition 
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Specification by Way of BEA's WebLogic Server , JavaWorld, (December 2000) 
<www JavaWorldxom/javaworld/j w- 1 2-2000/j w- 1 20 1 -weblogic_j).ht>. 

[053] LDAP process 246 A may allow EIPP server 240A to communicate with a 
configuration LDAP server and a User & Group (U& G) LDAP server (not shown). These 
LDAP servers store data (entries) in a hierarchical manner and include attributes describing 
information about the entries. Relationships between the entries may be inferred by strategic 
placement of the entries in the hierarchy. Accordingly, the configuration and U & G LDAP 
servers allow efficient retrieval of information through the use of the attributes and the hierarchy. 
The configuration LDAP server may store information that EIPP server 240A needs for proper 
operation. This information may include, for example, database configuration information and 
process manager appHcation definitions. The U & G LDAP server may store information about 
all of the users and groups defined within EIPP server 240A. It may also store information about 
purchasing entity's 220 A organizations and the people responsible for approving invoices 
(approvers). 

[054] JDBC process 248A interacts with database 250A and EIPP server 240A to 
facilitate data transactions. Database 250A may store information associated with the invoice 
information provided by providing entity 21 OA. Database 250A may house tables including data 
corresponding to items within one or more invoices generated by providing entity 21 OA, and 
departments associated with purchasing entity 220A. Database 250A may also store information 
that is used by biller manager 244A and process manager 242A to facilitate the approval/dispute 
processing features consistent with the present invention. Furthermore, database 250A may also 
store payment information associated with items for each invoice and process state information 
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associated with workflow processes that are executed by EIPP server 240A. Database 250A may 
be configured as an Oracle database system. 

[055] Process manager 242A is a web based workflow process that manages the routing 
of workflow through a predefined process. Biller manager 244 A works with process manager 
242A for invoice approval routing, dispute handling, enrollment process and invoice data 
distribution. Process manager 242A manages data that pertains to the current state of items in a 
given workflow process. This includes: (1) where an invoice is in an approval process; (2) the 
identification of a currently assigned approver for particular invoices; (3) the current state of a 
user enrolhnent process; and (4) the history of approvals within the processes. Process manager 
242A also allows the above-mentioned processes to be modified to better model the 
requirements of an individual business, in this case purchasing entity 220A. Process manager 
242A may also maintain a history database (not shown). The history database may include 
information that corresponds to each item in every invoice managed by the EIPP server 240A. 
The history database may be updated each time a change to an invoice or individual item within 
an invoice is made. Process manager 242A may be configured as a cluster of Enterprise 
JavaBeans (EJBs) firom Sun Microsystems, hic. of Palo Alto, Cahfomia. Enterprise JavaBeans 
;i are reusable software components that may be manipulated visually in a builder tool The EJBs 
include interfaces that (1) define how the EJB may be created or destroyed; (2) define methods 
I that may be invoked on a bean; and (3) a bean class that may implement a main business logic. 
Chents and EIPP server 240A may utihze the EJBs to create and edit workflow processes 
consistent with features of the present invention. 

[056] Biller manager 244A is responsible for managing the data access and data 
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244A manages access to any and all business data with respect to invoice data. This data 
includes: (1) invoice summary data; (2) invoice item detail data; (3) item status (currently in 
dispute, approved, etc.); (4) invoice payment information; (5) payment history; and (6) customer 
account information. As with process manager 242A, biller manager 244A may also be 
configured as EJBs. 

[057] Both process manager 242A and biller manager 244A use JDBC 248A to access 
database 250A for data storage and access. JDBCs are APIs that provides platform independent 
access to databases, such as database 250A. Biller manager 244A and process manager 242A 
each contain all of the business logic needed for a solution associated with an invoice problem. 
Process manager 242A and biller manager 244A each access their own particular data. For 
instance, biller manager 244A may only directly access business data, while process manager 
242A may only access process state information. When process manager 242A requires access 
to the business data, for example to display invoice data, it communicates directly with biller 
manager 244A to retrieve the required information from database tables stored within database 
25 OA. Process manager 242A may not directly access data that is managed by biller manager 
244A, and conversely, biller manager 244A may not access data managed by process manager 
242A. 

[058] Furthermore, both process manager 242A and biller manager 244A may include 
front-end presentation logic that is responsible for the communication of EJBs and delivering 
data populated forms to clients. The presentation logic may be written in the Java™ 
programming language, and may be configurable using defined templates. EIPP server 240A 
maybe implemented by multiple systems workmg together. FIG. 3 illustrates an conceptual 
view of how these systems may fit together. As shown in FIG. 3, the EJBs that make up biller 
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manager 244A and process manager 242A (330 and 340, respectively), reside on the same 
underlying application server, in this case EDPP server 240A. The biller manager 244A may 
include presentation logic 310 that enables biller manager 244 A to provide the invoice 
information to requesting entities. Also included in FIG. 3 are servlets 320. Servlets are small 
Java™ programs that extend the functionality of a server. Similarly to Common Gateway 
Interfaces (CGIs), servlets 320 may be executed dynamically when requested. Unlike CGIs, 
however, servlets may be executed as a separate thread, thus offering more scalability in their 
use than CGIs. FIG. 3 also shows how JDBC processes 350 and 370 interface with the process 
manager and biller manager EJBs to provide specific types of information. For instance, JDBC 
350 interacts with biller manager EJBs 330 to provide billing data, such as invoice information, 
whereas JDBC 370 interacts with process manager EJBs 340 to provide process state 
information. Both process manager EJBs 340 and biller manager EJBs 330 may interact with 
LDAP Java Developer Eat (JDK) process 360 to enable a software development kit (SDK) for 
enabling clients or entities to produce Java programs. The JDK is developed by Sun 
Microsystem's JavaSoft division and includes a JavaBeans component architecture and support 
for JDBC. 

[059] Biller manager 244A may faciUtate three levels of administration within system 
environment 200A. FIG. 2B illustrates these three levels of administration processes. As shown 
in FIG. 2B, Biller manager 244 A may facilitate a system administration process 21 OB, a provider 
administration process 220B, and a purchaser administration 230B. 

[060] System administration process 21 OB may use a system administration tool to 
perform system related administration processes, such as data management, events and 
administrators. FIG. 2C illustrates an exemplary view of system administration 21 OB including 
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these processes. The data management process 2 IOC may enable an administrator of EIPP 
server 240A to manually load invoice, user and department data; purge and recover the database 
of older data; and set an active archive directory where the loaded files are stored. The events 
process 220C may enable an administrator can create custom events that are triggered within the 
system at certain times. A graphical setup screen maybe provided to allow an administrator to 
define these events. And administrators process 230C may use the system administration tool to 
create additional administrators. 

[061] Provider administration process 220B may be used by providing entity 2 1 OA to 
setup and administer the business aspects of the B2B EIPP system consistent with features and 
principles of the present invention. FIG. 2D illustrates an exemplary view of the processes 
associated with provider administration process 220B. The processes that maybe included in 
provider administration process 220B may include profile process 21 OD, companies process 
220D, administrators process 230D, loading process 240D, activities process 250D and payment 
setup process 260D. The profile process 210D facilitates the management of a providing entity's 
profile. This may include, but is not limited to, contact addresses, fi-ont-end template 
information and phone numbers. The companies process 220D facilities the ability to create, 
manage and remove businesses that the providing entity may invoice. A company administrator 
associated with the providing entity 210A may have the ability to assign specific payment 
methods to purchasing entities that register with the B2B EIPP system facilitated by EIPP server 
240A. The administrators process 230D may enable the providing entity's administrator to 
create and manage new company administrators. The loading process 240D may enable the 
providing entity's administrator to review the status of invoice loads into EIPP server 240A. The 
activities process 250D may allow a providing entity's administi-ator to configure specific 
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, activities that maybe logged within system enviromnent 200 A, such as the logging in of users or 
when an invoice is paid. The payment setup process 260D may allow the creation and 
management of payment methods that are used within the B2B EIPP system facilitated by EIPP 
server 240 A, by providing entity 21 OA. 

[062] The purchaser administration process 230B facilitated by biller manager 244A 
may enable each purchasing entity to administer information pertaining to their business, the 
people accessing the system for their business and how it pays for its invoices. FIG. 2E 
illustrates an exemplary view of the processes that may be performed by purchaser 
administration process 230B. As shown in FIG. 2E, purchaser administration process 230B may 
include a profile process 210E, a departments process 220E, a members process 230E, and an 
activities process 240E. The profile process 210E may allow for an administrator of purchasing 
entity 220A to manage purchasing entity profile information. This information may include, but 
is not limited to, address information, company contacts and the payment method that is used to 
pay invoices from providing entity 21 OA. The departments process 220E may enable purchasing 
entity 220 A to add and modify the department hierarchy facihtated by the B2B EIPP server 
240A. The members process 230E may manage authorized users who are allowed to access the 
i| B2B EIPP system facilitated by EIPP server 240A. The authorized users are individuals that 
may interact with invoice data for approval, dispute or payment. These users may include 
; approvers and payers associated with purchasing entity 220A. The activities process 240E may 
enable an administrator associated with purchasing entity 220A to configure specific activities 
that should be logged within the B2B EIPP server 240A. These activities may include the 
logging in of users or when an invoice (or item of an invoice) is paid. 
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[063] In addition to the above levels of administration, the B2B EIPP system consistent 
with features and principles of the present invention may be associated with predefined processes 
that allow purchasing entity 220A to facilitate its invoice processing. Purchasing entity 220A 
may modify the predefined processes or create new ones to model its specific requirements. One 
such predefined process may include an enrollment process that handles the purchasing entity's 
end user sign up and registration. This may include registering approvers and/or payers that are 
authorized to approve, dispute or pay the invoices. 

[064] The enrollment process may involve login screens that are presented to an end 
user of the purchasing entity through a browser operating on a computer system. The computer 
system may or may not be located at purchasing entity 220A. For example, a user who is 
associated with purchasing entity 220A may be remotely located fi-om purchasing entity 220A, 
but may still interact with the enrollment process. The screens may include various buttons and 
icons to allow an end user to register using standard graphical user interface techniques. For 
instance, when a new user accesses the EIPP B2B system faciUtated by EIPP server 240 A, an 
ENROLL NOW button may be displayed in a login screen. Once activated by the user, the 
ENROLL NOW button may initiate a process that allows the user to enter personal information 
in an on-screen form displayed by the browser. The personal information may include, but is not 
limited to, name, email address, desired password and a company ID. The company ID may be 
provided by the user's manager prior to registering. 

[065] The enrollment process may then perform a check of the user' s email address to 
see if the user had previously registered. If the user already has an account with the EIPP B2B 
system, the enrolhnent process may allow the user to change the password. If the user is not a 
registered user, the process may find the company that the user is registering with (by using the 
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: company ID), and then send a confirmation email to the user in order to verify the email address. 
Included in the email may be an active link that the user may use to confirm all of the personal 
information that is required by the EIPP B2B system to create an account. 

[066] Once the user confirms the information, the enrollment process may pass an 
• account creation request to an administrator with the user's company, for instance purchasing 
entity 220A. The administrator may then use company resources to assign the user' s manager. 
From here, the enrolhnent process may then move to the user's manager, where the department 
number and approver are assigned. Once the manager has approved the user's request, the user 
is enrolled into the EPP B2B system. 

[067] Another predefined process that methods and systems consistent with the present 
invention may offer is a purchasing entity approval/dispute process. This process may enable a 
m purchasing entity to model their specific business requirements to define how invoices are to be 

rU approved and/or disputed. This process may include four sub-processes, Manager Approval 

Process, Approver Process, Delegation Process and Approval Amount Process. 
Y: [068] Manager Approval Process assigns an invoice initially to predefmed approvers for 

; departments listed on the invoice. As the predefmed approvers approve the invoice, the invoice 
ii is assigned for approval by the initial approver's manager, as may be defined in the U & G 
LDAP server. This process will continue until there are no more additional approvals reqmred. 

[069] FIG. 4A illustrates an exemplary Manager Approval Process consistent with 
features of the present invention. Once activated, the Manager Approval Process initializes 
common variables that are required throughout this process (Step 405A). If there are missing 

..w orr,c^s dcpartincnt numbers on tiie line items of the invoice (Step 410A; NO), the invoice enters another 
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process where the invoice is presented to a company administrator to assign the correct 
department numbers (Step 415A). 

[070] Once the department numbers have been assigned to each hne item, the invoice is 
assigned to the department approvers (USER APPROVAL STAGE). An assignment script 
which specifies who is required to perform the approval activity is recalculated each time 
someone approves the invoice. Once someone approves or disputes the invoice (Step 420A), 
their name is removed from a Ust of required approvers, and the Ust is recalculated. The 
department approver cycle continues until all department approvers have approved or disputed 
the Une items for which they responsible (Step 425 A). 

[071] After the initial approver (or approvers) approves the invoice, it may require the 
approval of their manager (Step 425A; YES). Accordingly, an automated process re-computes 
the new approvers to be the manager of the previous approvers (Step 428A). A manager is 
allowed to override the decision of their subordinates regarding invoice line approval or dispute. 
As in the USER APPROVAL STAGE, the assignment script for the Manager Approval Process 
is recalculated each time someone approves the invoice (Step 430A). The Manager Approval 
Process continues until all of the higher level managers approve or dispute all relevant line items 
in the invoice (Step 435A), 

[072] Once the approvals are complete (Step 43 5A; YES), the process determines if any 
of the line items are marked for dispute. If there are items that are in dispute (Step 440A; YES), 
the process invokes a sub-process that sends the disputed items to the providing entity for 
resolution (Step 445 A). The approved items are marked approved for payment by a designated 
account payable process that may be designated by the purchasing entity (Step 450A). Details of 
the dispute resolution process is described later with reference to FIG. 4E. 
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[073] Approver Process is similar to Manager approver Process except that the invoices 
do not go to the approver's manager for subsequent approvals. Instead, the invoices are sent to 
\ the approver's approver as may be defined in the U & G LDAP server. An approver's approver 
may be different than their manager, such as a financial approver designated for a particular 
department. 

[074] FIG. 4B illustrates an exemplary Approver Process consistent with features of the 
present invention. The Approver Process may be started automatically when invoices are first 
loaded into EIPP server 240A. As shown in FIG. 4B, the Approver Process initializes common 
variables that are required throughout this process (Step 405B). If there are missing department 
numbers on the line items of the invoice (Step 41 OB; NO), the invoice enters another process 
where the invoice is presented to a company administrator to assign the correct department 

, numbers (Step 41 5B). 

[075] Once the department numbers have been assigned to each Une item, the invoice is 
assigned to the department approvers (USER APPROVAL STAGE). An assignment script 
which specifies who is required to perform the approval activity is recalculated each time 
someone approves the invoice. Once someone approves or disputes the invoice (Step 420B), 

;; their name is removed from a list of required approvers, and the hst is recalculated. The 

II department approver cycle continues until all department approvers have been approved or 

K disputed the line items for which they responsible (Step 425B). 

[076] After the initial approver (or approvers) approves the invoice, it may require the 

'■' approval of a designated approver. Accordingly, as with the Manager Approval Process, an 
automated process re-computes a new approver to be the approver of the previous approvers. A 
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new approver is allowed to override the decision of their designated subordinate approvers 
regarding invoice line approval or dispute (Step 430B). 

[077] Once the approvals are complete, the process determines if any of the items are 
marked for dispute (Step 435B). If there are items that are in dispute (Step 435B; YES), the 
process invokes a sub-process that sends the disputed items to the providing entity for resolution 
(Step 440B). The approved items are marked approved for payment by a designated account 
payable process that may be designated by the purchasing entity (Step 445B), Details of the 
dispute resolution process is described later with reference to FIG. 4E. 

[078] The Delegation Process is a process where initially the invoice is assigned to a 
group of people within a purchasing entity. This group of people is responsible for reviewing the 
invoices and then assigning them to the correct person within the company for final approval. 

[079] FIG. 4C illustrates an exemplary Delegation Approval Process consistent with 
features of the present invention. The Delegation Approval Process maybe started automatically 
when invoices are first loaded by EIPP server 240A. As shown in FIG. 4C, the Delegation 
Approval Process initializes common variables that are required throughout this process (Step 
405C). If there are missing department number on the items of the invoice (Step 410C; NO), the 
invoice enters another process where the invoice is presented to a company administrator to 
assign the correct department number (Step 41 5C). 

[080] Once the department numbers have been assigned to each item, a designated 
company administrator may delegate the task of approving the invoice line items to a user fi-om 
the company (purchasing entity) (Step 420C). The delegated user should have sufficient 
permission to view all the line items in the invoice. Once the invoice is delegated to a user, the 
process allows that user to perform approval processing (USER APPROVAL STAGE). An 
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i indication of the delegated approver may be provided to EIPP server 240 A in order to allow the 
Delegation Process to facilitate the user approval stage. Once the delegated user approves or 
\ disputes the invoice (Step 425C), the process will look at each line item of the invoice and 
.; change the status of each line item that is pending to approved (or disputed) (Step 430C). The 
approved status indicator signifies that the line item has gone through the entire approval process 
and may used an indicator to an accounts payable approver to pay the invoice. 

[081] Once the approvals are complete, the process determines if any of the items are 
marked for dispute (Step 435C). If there are items that are in dispute (Step 435C; YES), the 
process invokes a sub-process that sends the disputed items to the providing entity for resolution 
(Step 440C). The approved items are marked approved for payment by a designated account 
■ payable process that may be designated by the purchasing entity (Step 445C). Details of the 
dispute resolution process is described later with reference to FIG. 4E. 

[082] Approval Amount Process examines an invoice and automatically approves 
invoices with an amount over (or under) a predetermined amount. This process enables 
: purchasing entities to minimize the cost of reviewing and approving invoices that may not worth 

the time required for people within the purchasing entity to examine and approve, 
i' [083] FIG. 4D illustrates an exemplary Amount Approval Process consistent with 

! features of the present invention. Once activated, the Amount Approval Process initializes 

common variables that are required throughout this process (Step 405D). If there are missing 
: , department numbers on the items of the invoice (Step 410D; NO), the invoice enters another 
process where the invoice is presented to a company administrator to assign the correct 
department nimibers (Step 41 5D). 
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[084] Once the department numbers have been assigned to each Une item, the process 
checks to see if the total amount of the invoice is less than a predetermined amount (Step 420D). 
If the invoice total is less than the predetermined amount (Step 420D; NO), the process marks all 
of the line items approved and valid for accounts payable to pay (Step 425D). In another aspect 
of the invention, the Amount Approval Process may be implemented to check individual items 
for approval based on the line item amount, 

[085] If, on the other hand, the invoice amount is above the predetermined amount (Step 
425D; YES), the invoice is assigned to the approvers of the departments for approval (USER 
APPROVAL STAGE). An assignment script which specifies who is required to perform the 
approval activity is recalculated each time someone approves the invoice. Once someone 
5 approves or disputes the invoice (Step 430D), their name is removed from a list of required 

m approvers, and the hst is recalculated. The department approver cycle continues until all 

rU department approvers have been approved or disputed the line items for which they responsible 

g (Step435D). 

[086] In another aspect of the invention, the Amount Approval Process may implement 
'\2 a manager approval stage, whereby after the initial approver (or approvers) approves the invoice, 

1 1 it may require the approval of their manager. Accordingly, an automated process re-computes 
ii the new approvers to be the manager of the previous approvers. A manager is allowed to 
override the decision of their subordinates regarding invoice line approval or dispute. An 
assignment script is recalculated each time someone approves the invoice, and approval process 
continues until all of the higher level managers approve or dispute all relevant items in the 
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[087] Once the approvals are complete (Step 43 5D; YES), the process determines if any 
of the items are marked for dispute. If there are items that are in dispute (Step 440D; YES), the 
process invokes a sub-process that sends the disputed items to the providing entity for resolution 
(Step 445D). The approved items are marked approved for payment by a designated account 
payable process that may be designated by the purchasing entity (Step 450D). Details of the 
dispute resolution process is described later with reference to FIG. 4E. 

[088] FIG. 4E illustrates an exemplary Dispute Resolution Process consistent v^ith 
; features of the present invention. The Dispute Resolution Process may be used by a providing 
entity to handle line item disputes by a purchasing entity. The Dispute Resolution Process may 
be started automatically from an invoice approval process in the event any items in an invoice 
are disputed. Once started, a resolver context field used to store a resolver's decision regarding a 
dispute is initialized (Step 410E). Invoices are assigned to a group called "Resolvers" in the 
providing entity. Any member of this group may examine an invoice and determine if the 
disputes are valid (Step 420E). The resolver may select specific disputed items and decide 
whether or not they are valid. Once a member of the resolver group completes its review of the 
invoice, all items whose disputes are marked as valid have their approval status changed to 
Dispute Vahd. Conversely, all invalid items disputes are marked as Dispute Invahd (Step 43 OE). 
Once a resolver completes its decision making, the process sends the status of the disputes to 
identified personal to take appropriate action within the providing entity (Step 440E). The status 
may be sent using an standard form of communication, including email. 

[089] In addition to the above mentioned processes, the EIPP B2B system may 
implement an Invoice Loading Process that facilitates the loading of invoices into EIPP server 
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entity for approval. Once a loader program completes the Invoice Loading Process for taking 
raw XML invoice data and bringing it into the system, a Loader Done Process may be initiated. 
The Loader Done process examines the new invoice data and initiates the correct process for the 
invoice for the appropriate purchasing entity. 

[090] To aid in the understanding of the features and principles of the present invention, 
FIGS 5 A-9 describe exemplary processes and representations that may be implemented when 
purchasing entity 220A prepares to handle an invoice prepared by providing entity 21 OA. The 
features described in FIGS. 5 A-9 may be implemented using the purchasing entity approval and 
dispute processes described in FIGS. 4A-4D. 

[09 1 ] As shown in FIG. 5 A providing entity 2 1 OA prepares an invoice for goods and 
services the entity provided to purchasing entity 220A (Step 505A). FIG. 5B shows an 
exemplary invoice 500B generated by providing entity 21 OA corresponding to purchases from 
purchasing entity 220A. Livoice 500B is exemplary only, and may be configured in any manner 
deemed appropriate by providing entity 210A. As shown, invoice 500B includes a plurality of 
line items (510B-350B) that may represent individual purchases by purchasing entity 220A, 
Invoice 500B may include a summary field 560B that provides a brief description of the type of 
goods and/or services that was purchased. Also, an amount field 570B corresponding to the 
goods and/or services that were purchased may be included in invoice 500B. In one aspect of the 
invention, invoice 500B may also include a department field 580B that indicates the department 
identifier that corresponds to a department within purchasing entity 220A that ordered the goods 
and/or services from providing entity 21 OA. 

[092] The invoice 500B may be configured into information that can be transmitted 
from providing entity 210A to the web server within EIPP server interface 230A. The web 
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server may generate an optional XML conversion of the invoice information (Step 51 OA). This 
; conversion enables EIPP server 240A to receive invoice data in a standard format that enables it 
to perform its B2B EIPP processing. Therefore, the format used by providing entity 21 OA to 
configure its invoice data is converted to a standard format using a loading program. Following 
the conversion process, biller manager 244A loads the XML converted data (Step 515A) and 
populates tables located within database 250A using JDBC 248A (Step 520A). The tables stored 
within database 250A may include, but is not limited to, summary tables and line item tables. 
Within a summary table, the information located in the summary field 560B of invoice 500B 
may be loaded. Within a line item table, corresponding amount and department fields 5606, 
580B may be stored. In another aspect of the invention, database 250A may store the converted 
invoice information within a single table. 

[093] FIG. 6 shows exemplary tables that may be stored within database 250A. As 
shown, line item table 600 includes information similar to that shown in invoice 500B illustrated 
, in FIG. 5B. Line item table 600 includes a plurahty of line items 610-650 that correspond to line 
! items 510B-550B. Also, line item table 600 may include a description field 660, and amount 
\ field 670 and a department field 680, similar to fields 560B, 570B and 580B shown in FIG. 5B. 
Additionally, line item table 600 may include a status field 690 that indicates whether a 
particular line item has been approved, disputed or not reviewed. Also shown in FIG. 6, 
summary table 605 may provide summary information associated with each line item. Field 615 
may provide description information similar to field 660 of line item table 600. Also, summary 
table 605 may include a summary information field that includes invoice information associated 
with each line item such as quantity, purchase order number, cost code SKU number. The 
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variety of invoice information may be maintained in these tables without departing from features 
and principles of the present invention. 

[094] After the invoice data is populated within database 250A, process manager 242A 
locates new line numbers that have not been reviewed by purchasing entity 220A. This may be 
performed by referring to the status field 690 of line item table 600 (Step 525 A). Next, biller 
manager 244A determines the department identifier corresponding to each line item that has not 
been reviewed (Step 5 3 OA). Working together with biller manager 244 A, process manager 
242A then determines an approver assigned to each department identifier that has been registered 
by purchasing entity 220A with EIPP server 240A and stored in the U & G LD AP server (Step 
535A), 

[095] In the event there is no approver associated with a given department (Step 535A; 
NO), a default process may be initiated (Step 545 A). This process may be configured by 
purchasing entity 220A as a back-up process that automatically associates line items that have no 
designated approver with a default entity designated by purchasing entity 220A. The designated 
entity may be a single approver, or may be a group of approvers, as designated by purchasing 
entity 220A. 

[096] On the other hand, if an approver has been associated with a particular department 
identifier (Step 53 5 A; YES), process manager 242 A creates an association between each line 
item that has not been reviewed and the designated approver for the department corresponding to 
the new line items (Step 540A). Coordinated processing between process manager 242A and 
biller manager 244A then stores the line item data, along with all associated purchase 
information such as summary data, amount, date of purchase etc., into database 250A. The 
stored information may be used for the generation of an in-box corresponding to each approver. 
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An in-box may be configured using e-mail type applications that interact with web browser 
, applications such that approvers or managers of purchasing entity 220A may determine whether 
; any new line items or invoices need approval. For example, referring to the invoice data 
illustrated in FIG. 6, process manager 242 A would associate line items 610 and 630 with the 
designated approver for units 101 and 102, respectively. For illustration purposes, manager 100 
has been registered as the approver for all invoices associated with units 101 and 102 and 
department 100, as shown in FIG. IB. Accordingly, process manager 242A may associate line 
items 610 and 630 with manager 100. Additionally, process manager 242A may associate hne 
item 620 with manager 200 (the designated approver for department 200), and associate line 
. g ' items 640 and 650 with manager 300 (the registered approver for department 300). 

CP [097] The processing of Une items within an invoice, as described above, may enable 

ffj EIPP server 240A to provide purchasing entity 220A and providing entity 2 1 OA with the 

^ opportunity to manage billing presentment and payment operations down to line items within 

r jj particular invoices. This level of granularity not only enables the businesses that interact with 

\2 : each other better approval and dispute resolution capabiUties, it also reduces the amoxmt of 

information that is transferred between selected entities in a given transmission. That is, instead 
1; of manager 100 receiving all of the hne items included in invoice 600, only information 
il associated with line items 610 and 630 are available to manager 100. 

[098] FIG. 7 shows an exemplary in-box 700 associated with manager 100 of 
purchasing entity 220 A. Manager 100 illustrated in FIG. 7 corresponds to manager 100 of 
eCompany, as depicted in FIG. 1 A. In-box 700 is generated by process manager 242 A when 
LAW OFFICES mattagcr 100 issues a request to EEPP server 240A to review invoices associated with department 
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the total number of invoices that include new line items that have not been reviewed, in-box 700 
may also include a listing 720 that includes the invoices that need reviewed by manager 100. in- 
box 700 may also include fields 730-770 that provide information associated with each invoice. 
Field 730 may provide a brief description of each invoice that needs reviewed, such as invoice 
number. Field 740 may provide the application that pertains to the workflow application that is 
being executed by EffP server 240A. Field 750 may describe the type of action that is required 
by manager 100, such as invoice approval. Field 760 may designate a priority level associated 
with an invoice and field 770 may indicate a particular due date firom which an invoice should be 
reviewed. The fields and configuration of in-box 700 illustrated in FIG. 7 are exemplary only 
and are not intended to be hmiting. Any number of configurations and fields may be 
implemented without departing fi:om the features and principles of the present invention. 

[099] hi another aspect of the invention, EffP server 240 A may be configured to create 
a table of associations between an approver and Une items. This table may be stored in database 
250A and accessed when the approver requests to perform approval or dispute operations 
consistent with features of the present invention. 

[0100] After creating associations between approvers and line items, EffP server 240 A 
may send a notification message to each approver in purchasing entity 220A that has new line 
items to be reviewed. The notification may be sent via email, or using wireless and wireline 
techniques, as well as any other form of notification that purchasing entity 220A desires to have 
approvers notified. Once an approver decides to perform approval operations, they may access 
an in-box by contacting EffP server 240A through the web server operating in interface 230. 
The B2B EffP system illustrated in FIG. 2 A may be HTML based. Therefore all access to EffP 
server 240A may be through a standard browser operating at the purchasing and providing 
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entities, or ay a computer system operated by an approver. Accordingly, an approver associated 
with purchasing entity 220A may utilize a standard browser to access the web server and Eff P 
server 240 A to access their in-box and perform approval or dispute functions. 

[0101] FIG. 8 illustrates an exemplary process associated with this aspect of the 
invention. The processes described with respect to FIG. 8 may be implemented using the 
approval processes previously described and illustrated in FIGS. 4A-4D. As shown in FIG. 8, an 
approver, for example manager 100, requests to access their in-box using a standard browser 
operating on a computer system. The computer system may or may not be located at purchasing 
entity 220A (Step 810). The web server operating in interface 230A receives the request and 
passes it to EIPP server 240A for processing. Billing manager 244A then accesses database 
250A (Step 820) to collect line item information for the generation of an in-box 700 associated 
with manager 100 (Step 830). Coordinated processing between process manager 242A and biller 
manager 244A enable EIPP server 240A to make available an in-box for access by the approver 
(Step 840). For instance, the U & G LDAP server may be accessed to retrieve information 
associated with an approver. In the above example, manager 100 is an approver for department 
100, thus the hne items associated with department 100 are retrieved from database 250A for 
i generation of the in-box, 

[0102] Following the example above, once in-box 700 is created, it is sent to the 
approver for display through the browser operating on the computer system that manager 100 is 
: utilizing to access EIPP server 240 A (Step 840). After in-box 700 is displayed, manager 100 
may select an invoice shown in listing 720 to view the line items associated with the selected 
invoice and perform approval/dispute processing (Step 850). FIG. 9 shows an exemplary invoice 
s DuHNER,L.L.p. associated with the first invoice hsted in listing 720 of invoice 700 ("eCompanyl002 ). 
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[0103] As shown, FIG. 9 includes an invoice 900 of line items 610 and 630 included in 
invoice 600 (labeled "eCompany 1002") that correspond to department 100. Invoice 900 may 
include detailed information associated with each line item such as a SKU number, quantity, 
total amount of line item purchase, approving department, purchase order nxunber, cost code 
associated with purchasing entity 220A and approval status. Manager 100 may review each line 
item and determine whether they should be approved for payment or not. If for example, 
manager 100 determines that the PBX switch components indicated in the first Une item was not 
an authorized purchase for department 100, that line item may be disputed. Manager 100 may 
select an action selector 910 that indicates manager lOO's decision to dispute the purchase. In 
one aspect of the invention, manager 100 may also select a predefined reason code firom a drop 
down menu 920 and supplement this code with a brief description of the reason for the dispute in 
input box 930. The configuration of invoice 900 is exemplary only and is not intended to be 
limiting. Accordingly, any number of configurations, description fields, reason codes and user- 
interactive windows may be implemented that are consistent with features and principles of the 
present invention. 

[0104] Referring back to FIG. 8, once manager 100 has completed approval/dispute 
processing for each line item in invoice 900, the reviewed invoice data may be submitted to EIPP 
server 240A using standard network communication techniques. The submitted reviewed 
invoice data is passed to EIPP server 240 A through the web server operating in interface 230. 
Process manager 242A may analyze the reviewed invoice with an approval hierarchy that may be 
set up by purchasing entity 220A to determme whether manager 100 has an approver designated 
to approve department lOO's invoices (Step 860). hi the event the approval hierarchy set up by 
purchasing entity 220A (such as the one depicted in FIG. IB) indicates that another approver is 
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required to review the subordinate approver's (manager 100) invoice (Step 860; YES), process 
manager 242A prepares the line items indicated in the reviewed invoice for placement in a 
generated in-box associated with the other approver (Step 870). Thus, another approver may 
, request access to their in-box and perform approval/dispute processing in a manner similar to 
that performed by manager 100. However, in the event the approver (manager 100) was the 
upper-most approver in the hierarchical approval scheme set-up by purchasing entity 220A, 
(Step 860; NO), process manager 242A initiates a purchasing entity's customized dispute 
resolution process (Step 880). Details of an exemplary customized approval/dispute process will 
be described later with reference to FIGS. 10 and 1 1 . 

[01 05] As described, methods and systems consistent with features and principles of the 
% present invention, enable a B2B EIPP system to filter and process line items within invoices 

rfl based on a customized approval hierarchy. This process eliminates the disadvantages of 

rU conventional B2B EIPP systems that require entire invoices to be exchanged between a 

3 purchasing and providing entity. Furthermore, with the implementation of the purchasing entity 

approval processes previously described, a purchasing entity may customize the manner by 
{2 ! which the approval workflow process is performed by EIPP server 240A. For instance, by 

implementing an approval amount process (as shown in FIG. 4E), a department may bypass 
particular line items that are below or above predefined dollar amounts. This process is 
especially advantageous to departments or companies that receive a large amount of invoices 
' each day because it enables these entities to reduce transactional costs associated with 
: performing approval/dispute processing for these line items. 

LAW orncBs [0106] FIG. 10 shows an exemplary process associated with an approver with top-level 

Finn EG AN, Henderson, \ 

Tdunner?l L , review authority in purchasing entity 220A performing a customized dispute resolution process. 
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The process described in FIG. 10 may be implemented using the processes previously described 
and illustrated in FIGS. 4A-4C. For exemplary purposes only, manager 000, as depicted in 
FIGS. 1 A and IB, will be considered the top-level approver for purchasing entity 220A. 
Therefore, manager 000 is designated as an approver for manager 100. As shown in FIG. 10, 
manager 000 may request access to their in-box by sending a request to EIPP server 240A. The 
request may be implemented by manager 000 logging-in using standard network login 
procedures (Step 1003). hi one aspect of the invention, prior to logging-in, manager 000 may be 
sent a notification by Eff P server 240A when invoices have been reviewed by subordinate 
approvers. The notification may be sent via email, or by using wireless and wireline techniques, 
or any other form of notification technique that purchasing entity 220 A desires to implement. 
With regard to the exemplary invoices described above, after manager 100 submitted invoice 
900, HIPP server 240A may be configured to send a notification message to an email account 
associated with manager 000. Accordingly, when manager 000 accesses their email account, a 
message indicating the review of invoice 900 by manager 100 may be presented. In response, 
manager 000 may then generate a request to view their in-box. 

[0107] Once EIPP server 240 A receives the request fi-om manager 000, process manager 
242A collects the appropriate information to generate the in-box associated with manager 000 
(Step 1005). As with the generated in-box 700 associated with manager 100, the in-box 
corresponding to manager 000 may include all mvoices that manager 000 has the authority to 
review. FIG. 1 1 shows an exemplary in-box associated with manager 000. 

[0108] As shown in FIG. 11, in-box 1 100 includes an in-box summary 1110 that may 
indicate the total number of items that have been reviewed by a number of approvers, in-box 
1 100 also includes a Usting 1 120 that presents the invoices that have been reviewed by approvers 
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that manager 000 is responsible for reviewing. As shown in FIG. 1 1 , hsting 1 1 20 includes the 
invoice (eCompanyl002) that manager 100 previously reviewed and submitted to EIPP server 
■ 240 A. As with in-box 700 illustrated in FIG. 7, invoice 1 100 may also include fields 1 130-1 170 
that provide information associated with each invoice. Field 1 130 may provide a brief 
: description of each invoice that needs reviewed, such as invoice number. Field 1140 may 
; provide the application that pertains to the workflow application that is being executed by EIPP 
, server 240A. Field 1150 may describe the type of action that is required by manager 000, such 
as invoice approval. Field 1 160 may designate a priority level associated with an invoice and 
field 1 170 may indicate a particular due date firom which an invoice should be reviewed. The 
; configuration of in-box 1 100 illustrated in FIG. 1 1 is exemplary only and are not intended to be 
, limiting. Any number of configurations and fields may be implemented without departing fi:om 
;: the features and principles of the present invention. 

[0109] Referring back to FIG. 10, once m-box 1 100 is displayed, manager 000 may view 
;■ the invoices listed therein and select the particular invoice that they wish to review (Step 1015). 
hi this case, invoice eCompanyl002 would be selected by manager 000 because it is the only 
invoice provided in listing 1 120. EIPP server 240A receives manager OOO's selection and 
jj processes it by generating a line item invoice and sending it to the manager's browser for 
i! display. FIG. 12 illustrates an exemplary line item mvoice 1200 associated with the invoice 
'. eCompanyl002 depicted in FIG. 11. 

[0 1 1 0] As shown in FIG. 1 2, line item invoice 1 200 includes detailed information 
; associated with the line items of invoice 500B, shown in FIG. 5B, that correspond to manger 100 
and department 100. The line item invoice 1200 may include similar information that was 
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total amount of line item purchase, approving department, purchase order number, cost code 
associated with purchasing entity 220A and approval status. Additional detailed information 
1210 associated with the invoice may also be included in Une item invoice 1200. Approval 
status 1220 may indicate to manager 000 a subordinate approver's decision to dispute or approve 
particular line items. As shown in FIG. 12, approval status 1220 indicates to manager 000 that 
the approver for department 100 (manager 100) has disputed a Ime item in invoice 
eCompanyl002. As with invoice 900, invoice 1200 may also include reason codes and 
description blocks for indicating the reason the lower-level approver disputed a particular line 
item. Manager 000 reviews invoice 1200 to determine whether Ihey are going to approve or 
dispute (reject) the subordinate approver's decision associated with each line item (Step 1020). 

[0111] In the event line item invoice 1200 does not include a dispute (Step 1020; NO), 
manager 000 may decide to accept or override approvals made by manager 100 in any line item 
listed in invoice 1200 (Step 1025). In one aspect of the invention, if manager 000 decides to 
accept a line item, the appropriate action icon 1230 may be selected to indicate the approval. M 
the event manager 000 decides to accept each line item in invoice 1200 (Step 1025; ACCEPT), a 
customized post-approval process may be initiated (Step 1030). This may include making 
available information corresponding to the invoice 1200 to one or more payers in purchasing 
entity 220A for payment processing. Payers may also have associated in-boxes managed by 
EIPP server 240A that may include the submitted invoice information from a approver. The 
manner by which purchasing entity 220A configures a payment process may vary depending on 
the requirements of the company, and is not limited to the above examples. 

[01 12] On the other hand, if manager 000 decides to dispute (override) a particular line 
item in invoice 1200 (Step 1025; OVERRIDE), process manager 242 A may flag the line item 
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rejected by manager 000 as a disputed line item in invoice 1200 (Step 1035). Processing then 
■ proceeds to Step 1040. 

[0113] At Step 1040, manager 000 may decide to accept or dispute (override) any 
: disputes that are indicated in invoice 1200, If manager 000 decides to override any disputed 
items by manager 100 (Step 1045; NO), the customized payment process defined by purchasing 
entity 220A may be initiated, as previously described (Step 1030). One reason for initiating the 
payment process is because manager 000 is considered the top-level approver in the exemplary 
approval hierarchical structure set-up by purchasing entity 220A, Accordingly, if manager 000 
decides to approve all of the line items in a particular invoice — even those line items that have 
, been disputed by a subordinate manager — ^the decision by manager 000 may be considered final, 
and payment of the invoice is authorized. 

[0114] However, if manager 000 decides to accept a disputed line item in invoice 1200 
(Step 1045; YES), EIPP server 240A may update database 250A to indicate this in preparation 
for a dispute resolution process between purchasing entity 220A and providing entity 21 OA (Step 
1050). For example, if manager 000 decides to accept the decision by manager 100 to dispute 
, the furst line item for PBX Switch Components, the dispute action icon 1230 may be selected. In 
1 1 this case, once this submission was received and processed by EIPP server 240A, process 
I manager 242A, possibly working with biller manager 244A, may access database 250A to toggle 
the status field 690 of line item 630 (associated with the line item in invoice 1200 for PBX 

Switch Components). The modification of the value in status field 690 enables EIPP server 240A \ 

I 

to indicate a disputed or rejected line item. Processes manager 242 A may perform this fimction \ 

" i 

for every line item in any particular invoice that has been disputed by a particular upper 
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invoice information is submitted to EEPP server 240A and manager 000 may log-off from the 
B2B EIPP system. 

[01 15] In addition to the above description, the approval/dispute process associated with 
a upper-management approver maybe configured as basic or complex as purchasing entity 220A 
desires. For instance, in one aspect of the invention, in the event an approver overrides a 
subordinate approver's decision on a line item, process manager 242 A may re-route the 
overridden line item back to subordinate approver's in-box for subsequent processing. 
Additionally, purchasing entity 220A may also implement an approval amount process that 
allows process manager 242A to automatically approve line items over or under a predefined 
dollar amount that have been approved by subordinate approvers. There are a variety of options 
available to purchasing entity 220A for configuring an approval/dispute process and are not 
limited to the examples described above. 

[0116] FIG. 13 shows an exemplary dispute resolution process consistent with features 
and principles of the present invention. The process described in FIG. 13 may be implemented 
using the Dispute Resolution Process previously described and illustrated in FIG. 4E. As shown 
in FIG. 13, process manager 242 A may initiate a dispute resolution process in the event database 
250A includes an invoice with line items that have been flagged as disputed by a particular upper 
management approver (Step 1310). The dispute resolution process may be configured by 
providing entity 21 OA to facihtate a coordinated process of handling disputes with purchasing 
entity 220A. The dispute resolution process may involve a variety of workflow processes that 
allow providing entity 21 OA to determine whether or not a line item disputed by purchasing 
entity 220A is accepted. 
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[01 17] In perfonning its dispute resolution process, providing entity 210A may accept or 
reject a line item that has been disputed by an approver corresponding to purchasing entity 220A. 
If accepted, (Step 1320; ACCEPTED), the line item may be flagged by process manager 242A as 
accepted and this indication maybe stored in a line item table associated with providing entity 
210A in database 250A (Step 1330). In one aspect of the invention, providing entity 210A may 
; generate a new invoice to reflect the accepted dispute by purchasing entity 220 A. Information 
associated with the new invoice may then by provided to EIPP server 240A for subsequent 
review by approvers within purchasing entity 220A. However, if providing entity 210A rejects a 
; disputed line item (Step 1320; REJECTED), the line item may be flagged as rejected in a sunilar 
table (Step 1340). In either case, once providing entity 21 OA has decided on a line item dispute, 
i process manager 242A may generate and make available a notification to a designated person 
within purchasing entity 220A indicating the providing entity 210A decision (Step 1350). This 
notification may be presented using a number of techniques including, but not limited to, email, 
wireless notifications, wireline notifications, and any other form of communication that 
purchasing entity 220A desires to implement. The notification may take place through EIPP 
server 240A. Following the notification of a rejected line item, providing and purchasing entities 
!i 210A, 220A may initiate a resolution process that may involve a direct interface between the 

i i 

two. This may include direct contact between designated personal for each entity to resolve the 
- disputed line item. EIPP server 240 A may facilitate communications between the two entities 
'I through the web server operating in interface 230, m the event electronic communications is 
; involved in such resolution. 

[01 18] As described, the above dispute resolution process facilitated by methods and 
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items within a given invoice and provide notification to both a provider of goods and/or services 
and a purchaser of these goods and/or services, in order to facilitate resolution procedures 

: between these two entities. The resolution process may enable either entity to decide whether its 
worth the time to dispute a given line item, based on a plurality of factors including the amount 

' of the item's purchase and the type of goods and/or services involved. This Hne item granularity 
prevents a company from having to place an entire invoice on hold while a disputed line item 
within the invoice is being resolved. Accordingly, a providing entity may utilize the features of 
the present invention to obtain payment for a portion of an invoice while disputing another, thus 
giving the providing entity funds that would not be normally available if the entire invoice had to 
be processed through a dispute resolution procedure. 

[0119] Other embodiments of the invention will be apparent to those skilled in the art 
from consideration of the specification and practice of the invention disclosed herein. It is 
intended that the specification and examples be considered as exemplary only, with a true scope 

\ and spirit of the invention being indicated by the following claims. 
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